This application generally relates to testing an implementation of a communication protocol, such as a network protocol or an application-layer protocol. More particularly, it relates to generating test cases based on network traffic.
A “communication protocol” refers to an exchange of data or messages in a known, structured format. Specifically, a protocol refers to what is being communicated (for example, the data or message content). Types of protocols include, for example, networking protocols (including network packets) and application-layer protocols (application program interfaces or “APIs”, including API calls, remote method invocation (RMI), and remote procedure call (RPC)).
The implementation of a communication protocol is tested using test cases. A test case generally includes one or more message exchanges between two or more entities (e.g., two devices or two processes). A test case (e.g., the messages that are exchanged) can be generated manually or automatically, as described in U.S. patent application Ser. No. 11/514,809, filed Sep. 1, 2006, entitled “Automated Generation of Attacks for Analyzing the Security of Communication Protocols and Channels” (“the '809 Application”), which is incorporated by reference herein in its entirety.
A protocol is generally defined by a specification. The specification can be expressed in a variety of formats, such as an Internet Engineering Task Force (IETF) Request for Comments (RFC), Web Services Description Language (WSDL), Backus-Naur Form (BNF), Augmented BNF (ABNF), regular expressions, Interface Definition Language (IDL), Document Type Definition (DTD), Management Information Base (MIB), eXtended Markup Language (XML) schema, eXternal Data Representation (XDR), and Abstract Syntax Notation 1 (ASN.1). The '809 Application describes software programs that parse machine-readable protocol specifications and generate test cases based on the specifications.
Communication-oriented test cases (for layer-2 through application-layer protocols) are conventionally generated by starting with a protocol specification and then creating scripts or tools that can generate the network traffic (based on the specification) to interact with a system under test. Translating a specification to a set of test cases is difficult and time-consuming. Because of this, using a specification to create test cases works best when the specification itself and the different implementations are fairly static. When the specification is in flux and/or the implementation customizes the protocol by adding structured extensions, the test cases that were generated based on the original protocol and its specification quickly become obsolete and irrelevant.